The following is from Azure Administrator Training lab for AZ-103

Azure MFA Concepts

Azure Multi-Factor Authentication (MFA) helps safeguard access to data andapplications while maintaining simplicity for users. It provides additionalsecurity by requiring a second form of authentication and delivers strongauthentication through a range of easy to use authentication methods.

For organizations that need to be compliant with industry standards, such asPCI DSS version 3.2, MFA is a must have capability to authenticate users.Beyond being compliant with industry standards, enforcing MFA toauthenticate users can also help organizations to mitigate credential theftattacks.

The security of MFA two-step verification lies in its layered approach.Compromising multiple authentication factors presents a significantchallenge for attackers. Even if an attacker manages to learn the user’spassword, it is useless without also having possession of the additionalauthentication method. Authentication methods include:

• Something you know (typically a password)
• Something you have (a trusted device that is not easily duplicated, like aphone)
• Something you are (biometrics)

MFA Features

Get more security with less complexity. Azure MFA helps safeguard access todata and applications and helps to meet customer demand for a simple sign-in process. Get strong authentication with a range of easy verification options—phone call, text message, or mobile app notification—and allow customersto choose the method they prefer.

Mitigate threats with real-time monitoring and alerts. MFA helps protectyour business with security monitoring and machine-learning-based reportsthat identify inconsistent sign-in patterns. To help mitigate potential threats,real-time alerts notify your IT department of suspicious account credentials.

Deploy on-premises or on Azure. Use MFA Server on your premises to helpsecure VPNs, Active Directory Federation Services, IIS web applications,Remote Desktop, and other remote access applications using RADIUS andLDAP authentication. Add an extra verification step to your cloud-basedapplications and services by turning on Multi-Factor Authentication in AzureActive Directory.

Use with Office 365, Salesforce, and more. MFA for Office 365 helps secureaccess to Office 365 applications at no additional cost. Multi-FactorAuthentication is also available with Azure Active Directory Premium andthousands of software-as-a-service (SaaS) applications, including Salesforce,Dropbox, and other popular services.

Add protection for Azure administrator accounts. MFA adds a layer ofsecurity to your Azure administrator account at no additional cost. When it’sturned on, you need to confirm your identity to create a virtual machine,manage storage, or use other Azure services.

For more information, you can see:

Multi-factor authentication – https://azure.microsoft.com/en-us/services/multi-factor-authentication/

 

MFA Authentication Options

Method	Description
Call to phone	Places an automated voice call. Theuser answers the call and presses #in the phone keypad to authenticate.The phone number is notsynchronized to on-premises ActiveDirectory. A voice call to phone isimportant because it persiststhrough a phone handset upgrade,allowing the user to register themobile app on the new device.
Text message to phone	Sends a text message that containsa verification code. The user isprompted to enter the verificationcode into the sign-in interface. Thisprocess is called one-way SMS.Two-way SMS means that the usermust text back a particular code.Two-way SMS is deprecated and notsupported after November 14, 2018.Users who are configured for two-way SMS are automaticallyswitched to call to phoneverification at that time.
Notification through mobile app	Sends a push notification to yourphone or registered device. Theuser views the notification andselects Approve to completeverification. The MicrosoftAuthenticator app is available forWindows Phone, Android, and iOS.Push notifications through themobile app provide the best userexperience.
Verification code from mobile app	The Microsoft Authenticator appgenerates a new OATH verificationcode every 30 seconds. The userenters the verification code into thesign-in interface. The MicrosoftAuthenticator app is available forWindows Phone, Android, and iOS.Verification code from mobile appcan be used when the phone has nodata connection or cellular signal.

✔️ There is also a selection to cache passwords so that users do not have toauthenticate on trusted devices. The number of days before a user must re-authenticate on trusted devices can also be configured with the value from 1to 60 days. The default is 14 days.

 

Enabling MFA

To enable MFA, go to the User Properties in Azure Active Directory, and thenthe Multi-Factor Authentication option. From there, you can select the usersthat you want to modify and enable for MFA. You can also bulk enable groupsof users with PowerShell.

✔️ On first-time sign-in, after MFA has been enabled, users are prompted toconfigure their MFA settings. For example, if you enable MFA so that usersmust use a mobile device, users will be prompted to configure their mobiledevice for MFA. Users must complete those steps, or they will not bepermitted to sign in, which they cannot do until they have validated that theirmobile device is MFA-compliant.

 

Enabling MFA for Global Admins

Azure MFA is included free of charge for global administrator security.Enabling MFA for global administrators provides an added level of securitywhen managing and creating Azure resources like virtual machines,managing storage, or using other Azure services. Secondary authenticationincludes phone call, text message, and the authenticator app.

You can use the portal to enable MFA for administrators. MFA configurationis done through the Active Directory blade and the Configure MFA link.

Once you have located the global administrator of choice you can EnableMFA.

✔️ Remember you can only enable MFA for organizational accounts storedin Active Directory. These are also called work or school accounts.

 

Requiring MFA

Conditional access is a capability of Azure AD (with an Azure AD Premiumlicense) that enables you to enforce controls on the access to apps in yourenvironment based on specific conditions from a central location. With AzureAD conditional access, you can factor how a resource is being accessed intoan access control decision. By using conditional access policies, you canapply the right access controls under the required conditions.

Conditional access comes with six conditions: user/group, cloud application,device state, location (IP range), client application, and sign-in risk. You canuse combinations of these conditions to get the exact conditional accesspolicy you need. Notice on this image the conditions determine the accesscontrol from the previous topic.

With access controls, you can either Block Access altogether or Grant Accesswith additional requirements by selecting the desired controls. You can haveseveral options:

• Require MFA from Azure AD or an on-premises MFA (combined with ADFS).
• Grant access to only trusted devices.
• Require a domain-joined device.
• Require mobile devices to use Intune app protection policies.

Requiring additional account verification through MFA is a commonconditional access scenario. While users may be able to sign-in to most ofyour organization’s cloud apps, you may want that additional verification forthings like your email system, or apps that contain personnel records orsensitive information. In Azure AD, you can accomplish this with aconditional access policy

✔️ The Users and Groups condition is mandatory in a conditional accesspolicy. In your policy, you can either select All users or select specific usersand groups.

 

Trusted IPs

Trusted IPs is a feature to allow federated users or IP address ranges tobypass two-step authentication. Notice there are two selections in thisscreenshot.

Which selections you can make depends on whether you have managed orfederated tenants.

• Managed tenants. For managed tenants, you can specify IP ranges thatcan skip MFA.
• Federated tenants. For federated tenants, you can specify IP ranges andyou can also exempt AD FS claims users .

✔️ The Trusted IPs bypass works only from inside of the company intranet. Ifyou select the All Federated Users option and a user signs in from outside thecompany intranet, the user must authenticate by using two-step verification.The process is the same even if the user presents an AD FS claim.

 

One-time Bypass

The one-time bypass feature allows a user to authenticate a single timewithout performing two-step verification. The bypass is temporary andexpires after a specified number of seconds.

✔️ In situations where the mobile app or phone is not receiving a notificationor phone call, you can allow a one-time bypass, so the user can access thedesired resource.

 

Fraud Alerts

Configure the fraud alert feature so that your users can report fraudulentattempts to access their resources. Users can report fraud attempts by usingthe mobile app or through their phone. Block user when fraud is reported: Ifa user reports fraud, their account is blocked for 90 days or until anadministrator unblocks their account. An administrator can review sign-insby using the sign-in report and take appropriate action to prevent futurefraud. An administrator can then unblock the user’s account.

Code to report fraud during initial greeting: When users receive a phone callto perform two-step verification, they normally press # to confirm their sign-in. To report fraud, the user enters a code before pressing #. This code is 0 bydefault, but you can customize it.

Block user when fraud is reported. If a user reports fraud, their account isblocked for 90 days or until an administrator unblocks their account. Anadministrator can review sign-ins by using the sign-in report and takeappropriate action to prevent future fraud. An administrator can then unblockthe user’s account.

Code to report fraud during initial greeting. When users receive a phone callto perform two-step verification, they normally press # to confirm their sign-in. To report fraud, the user enters a code before pressing #. This code is 0 bydefault, but you can customize it.

✔️ The default voice greetings from Microsoft instruct users to press 0# tosubmit a fraud alert. If you want to use a code other than 0, record andupload your own custom voice greetings with appropriate instructions foryour users.

 

MFA Licensing and Pricing

There are three pricing methods for Azure MFA.

Consumption based billing. Azure MFA is available as a stand-alone servicewith per-user and per-authentication billing options.

• Per user. You can pay per user. Each user has unlimited authentications.Use this model if you know how many users you have and can accuratelyestimate your costs.
• Per authentication. You can pay for a bundle (10) of authentications.Use this model when you are unsure how many users will participate inMFA authentication.

MFA licenses included in other products. MFA is included in Azure ADPremium, Enterprise Mobility Suite, and Enterprise Cloud Suite.

Direct and Volume licensing. MFA is available through a MicrosoftEnterprise Agreement, the Open Volume License Program, the Cloud SolutionProviders program, and Direct, as an annual user based model.

✔️ Which of these licensing options is appropriate for your organization?

For more information, you can see:

MFA Pricing – https://azure.microsoft.com/en-us/pricing/details/multi-factor-authentication/

 

Azure AD Identity Protection

Current threat landscape – credential theft

In today’s IT environment malicious users use credential theft attacks as oneof the main ways to gain access to your environment. Credential theft attacksare those in which an attacker initially gains highest-privilege access to acomputer on a network and then uses freely available tooling to extractcredentials from the sessions of other logged-on accounts. Depending on thesystem configuration, these credentials can be extracted in the form of hashes,tickets, or even plaintext passwords. Many IT professionals believe thatidentity is the new boundary layer for security, supplanting that role from thetraditional network-centric perspective.

Securing systems with Azure AD Identity Protection

Microsoft has secured cloud-based identities for more than a decade. AzureAD Identity Protection is a service that helps to ward off compromised useraccounts and configuration vulnerabilities. This service enables you to usethe same protection systems Microsoft uses to secure identities in yourenvironment.

The service is available from Azure Marketplace and must be set up by anorganization’s global administrator. Azure AD Identity Protection is availableto subscribers to Microsoft’s Enterprise Mobility Suite and/or the Azure ADPremium P2 service.

Azure AD Identity Protection enables you to:

• Detect potential vulnerabilities affecting your organization’s identities
• Configure automated responses to detected suspicious actions that arerelated to your organization’s identities
• Investigate suspicious incidents and take appropriate action to resolvethem

Identity Protection capabilities

• Azure Active Directory Identity Protection analyses your configurationand detects vulnerabilities that can have an impact on your user’sidentities.
• Azure AD uses adaptive machine learning algorithms and heuristics todetect suspicious actions that are related to your user’s identities. Thesystem creates a record for each detected suspicious action. Theserecords are also known as risk events.
• Azure AD Identity Protection lets you set risk-based Conditional Accesspolicies to automatically protect your users. The following topics coversome of these policies in more detail.

The following screenshot shows the Azure AD Identity Protection dashboard.

The dashboard gives access to:

• Reports such as Users flagged for risk, Risk events and Vulnerabilities
• Settings such as the configuration of your Security Policies,Notifications and multi-factor authentication registration

 

Azure AD Risk Events

The vast majority of security breaches occur when attackers gain access to anenvironment by stealing a user’s identity. Discovering compromised identitiesis no easy task. Azure Active Directory uses adaptive machine learningalgorithms and heuristics to detect suspicious actions that are related to youruser accounts. Each detected suspicious action is stored in a record called arisk event.

Currently, Azure Active Directory detects six types of risk events:

✔️ Not shown in the screen shot is the Sign-ins from IP addresses withsuspicious activity risk event. This risk event type identifies IP addresses fromwhich a high number of failed sign-in attempts were seen, across multipleuser accounts, over a short period of time. This matches traffic patterns of IPaddresses used by attackers, and is a strong indicator that accounts are eitheralready or are about to be compromised.

• Leaked credentials. When cybercriminals compromise valid passwordsof legitimate users, they often share those credentials. This is usuallydone by posting them publicly on the dark web or paste sites or bytrading or selling the credentials on the black market. The Microsoftleaked credentials service acquires username / password pairs, andchecks them against AAD users’ current valid credentials. When a matchis found, it means that a user’s password has been compromised, and aleaked credentials risk event is created.
• Sign-ins from anonymous IP addresses. This risk event type identifiesusers who have successfully signed in from an IP address that has beenidentified as an anonymous proxy IP address. These proxies are used bypeople who want to hide their device’s IP address, and may be used formalicious intent.
• Impossible travel to atypical locations. This risk event type identifiestwo sign-ins originating from geographically distant locations, where atleast one of the locations may also be atypical for the user, given pastbehavior. Among several other factors, this machine learning algorithmtakes into account the time between the two sign-ins and the time itwould have taken for the user to travel from the first location to thesecond, indicating that a different user is using the same credentials.
• Sign-in from unfamiliar locations. This risk event type considers pastsign-in locations (IP, Latitude / Longitude and ASN) to determine new /unfamiliar locations. The system stores information about previouslocations used by a user, and considers these “familiar” locations. Therisk event is triggered when the sign-in occurs from a location that’s notalready in the list of familiar locations. The system has an initiallearning period of 30 days, during which it does not flag any newlocations as unfamiliar locations. The system also ignores sign-ins fromfamiliar devices, and locations that are geographically close to afamiliar location.
• Sign-ins from infected devices. This risk event type identifies sign-insfrom devices infected with malware, that are known to activelycommunicate with a bot server. This is determined by correlating IPaddresses of the user’s device against IP addresses that were in contactwith a bot server.

 

User Risk Policy

Azure AD analyzes each user-sign in for evidence of a compromised accountor any suspicious activity, also known as risk events (described in theprevious topic).

For risk events that the system detects, you can resolve those events manually,or you can configure conditional access policies that apply to a specific userrisk level or the sign-in risk level. This topic describes the user risk policy andhow to configure it.

The system can detect some risk events in real-time but other risk eventsrequire more time to analyze pattern and behavior, such as risk events arisingfrom impossible travel to atypical locations. The systems needs time to beable to distinguish between a sign-in based on a user’s regular behavior andan atypical sign-in. If the locations are geographically distant and the timedelay between the sign-ins is insufficient for that user to have attempted tosign in from one location and then the other, that is an indication that theaccount has likely been compromised and a different user is using the user’scredentials.

When the system detects a risk event for a user that hasn’t been resolved it isconsidered an active risk event. A user risk is any active risk event associatedwith a particular user. Azure AD calculates the probability that a user hasbeen compromised and assigns a user risk level of low, medium, or high.

A user risk policy lets you block access access to resources or require apassword change to reset the user’s account to a non-compromised state.

Configure the user risk policy

You access the user risk policy from the Configure section of the Azure ADIdentity Protection blade. From the Azure AD Identity Protection – User riskpolicy blade, configure the User risk remediation policy.

• Select the users and groups the policy applies to
• Assign the condition (Low and above, Medium and above, or High)
• The access type you will enforce for the user based on sign-in risk level
• Set Enforce Policy to On

Blocking a sign-in:

• Prevents the generation of new user risk events for the affected user
• Enables administrators to manually remediate the risk events affectingthe user’s identity and restore it to a secure state

Best practices

When setting user risk policy, it is recommended you balance theorganizational and productivity impact of a High threshold with the lessstringent levels of Medium and Low. A Medium threshold provides a balancebetween usability and security.

When setting the policy:

• Use a High threshold during initial policy roll out, or if you must reducechallenges seen by end users.
• Use a Low threshold if your organization requires greater security.Selecting a Low threshold introduces additional user sign-in challenges,but increased security.

 

Sign-in Risk Policy

With the user risk, Azure AD detects the probability that a user account hasbeen compromised. As an administrator, you can configure a user riskconditional access policy, to automatically respond to a specific user risklevel.

Azure AD detects risk event types in real-time and offline. Each risk event thathas been detected for a user sign-in of a user contributes to a risky sign-in. Arisky sign-in signifies a possible attempt to perform a sign-in by someoneother than the legitimate owner of the associated user account.

Azure AD analyzes each user sign-in with the intention of detecting suspiciousactions, or risk events, that come along with the sign-in. For example, one ofthe risk events discussed in a previous topic, such as a sign-in attemptedthrough an anonymous IP address. Based on the risk events detected, AzureAD calculates a value representing the probability (low, medium, high) thatthe sign is not performed by the legitimate user. The probablility is referred toas sign-in risk level.

Configure the sign-in risk policy

You access the sign-in risk policy from the Configure section of the Azure ADIdentity Protection blade. From the Azure AD Identity Protection – Sign-inrisk policy blade, configure the Sign-in risk remediation policy.

• Select the users and groups the policy applies to
• Assign the condition (Low and above, Medium and above, or High)
• The access type you will enforce for the user based on sign-in risk level
• Set Enforce Policy to On

You can configure a sign-in risk security policy to require MFA:

Important considerations

If you want to require multi-factor authentication (MFA) for risky sign-ins,enable the multi-factor authentication registration policy for the affectedusers and require those users to sign in to a non-risky session to perform anMFA registration.

In addition to the best practices in the previous topic, also consider:

• Omit users who are likely to generate a lot of false-positives. Forexample developers, or security analysts.
• Omit users in sites where it’s not realistic to enable the policy. Forexample, no access to helpdesk.

✔️ The sign-in risk policy is applied to all browser traffic and sign-ins usingmodern authentication, but not to applications using older security protocols.

 

 

Security Best Practices

Many consider identity to be the new boundary layer for security, taking overthat role from the traditional network-centric perspective. To help you getstarted, there is an Azure identity management and access control securitybest practices page. The best practices were derived from consensus opinionand Azure platform capabilities and feature sets.

• Centralize your identity management. Ensure that IT can manageaccounts from one single location.
• Enable Single Sign-On (SSO). Provide your users the ability to use thesame set of credentials to sign in and access the resources that theyneed, regardless of whether this resource is located on-premises or in thecloud.
• Deploy password management. leverage the self-service password resetcapability and customize the security options to meet your businessrequirements.
• Enforce MFA for users. Enable Azure MFA for your users. This will adda second layer of security to user sign-ins and transactions.
• Use role-based access control (RBAC). Apply the principle of leastprivileges.
• Control locations where resources are created using ResourceManager. Create security policies with definitions that describe theactions or resources that are allowed and denied.
• Guide developers to leverage identity capabilities for SaaS apps. Ensuredevelopers use a secure methodology to develop SaaS apps. Register anyapplication that outsources authentication to Azure AD.
• Actively monitor for suspicious activities. Use Azure AD Premiumanomaly reports and Azure AD identity protection capabilities.

✔️ Take a minute to go through each item in the reference link. Are youfollowing these best practices? In this course we focus on enforcing MFA forusers and implementing RBAC, but security is much more than that.

For more information, you can see:

Azure Identity Management and access control security best practices –https://docs.microsoft.com/en-us/azure/security/azure-security-identity-management-best-practices

 

Self-Service Password Reset

The large majority of helpdesk calls in most companies are requests to resetpasswords for users. Enabling Self-service password reset (SSPR) gives theusers the ability to bypass the helpdesk and reset their own passwords.

To configure self-service password reset, you first determine who will beenabled to use self-service password reset. From your existing Azure ADtenant, on the Azure Portal under Azure Active Directory select Passwordreset.

In the Password reset properties there are three options: None, Selected, andAll.

The Selected option is useful for creating specific groups who have self-service password reset enabled. The Azure documentation recommendscreating a specific group for purposes of testing or proof of concept beforedeploying to a larger group within the Azure AD tenant. Once you are readyto deploy this functionality to all users with accounts in your AD Tenant, youcan change the setting to All.

✔️ Azure Administrator accounts will always be able to reset their passwordsno matter what this option is set to.

 

SSPR Authentication Methods

After enabling password reset for user and groups, you pick the number ofauthentication methods required to reset a password and the number ofauthentication methods available to users.

At least one authentication method is required to reset a password, but it is agood idea to have additional methods available. You can choose from emailnotification, a text or code sent to user’s mobile or office phone, or a set ofsecurity questions.

Regarding the security questions, these can be configured to require a certainnumber of questions to be registered for the users in your AD tenant. Inaddition, you must configure the number of correctly answered securityquestion that are required for a successful password reset. There are a largenumber of security questions. Security questions can be less secure than othermethods because some people might know the answers to another user’squestions.

✔️ At the time of this writing Mobile app notification and Mobile app codeare in preview.

 

SSPR Registration

If you want your users to register for password reset, you can require thatthey register when they sign in through Azure AD. You can enable this optionfrom your directory’s Password reset pane by enabling the Require Users toRegister when Signing in option on the Registration tab. Administrators canrequire users to re-register after a specific period of time. They can set theNumber of days before users are asked to reconfirm their authenticationinformation option to 0 to 730 days. After you enable this option, when userssign in they see a message that says their administrator has required them toverify their authentication information.

There are two modes to register: interrupt and manage.

• Interrupt mode, is a wizard-like experience, shown to a user when theyregister or refresh their security info at sign in.
• Manage mode is part of the user’s profile and allows them to managetheir security info.

Previously, there were two different ways for users to register for Azure MFAand SSPR. Now, in preview, users can register once and get the benefits ofboth Azure MFA and SSPR.

✔️You should consider pre-populating some authentication data for yourusers. That way users don’t need to register for password reset before they areable to use SSPR. As long as users have provided the authentication data thatmeets the password reset policy you have defined, they are able to reset theirpasswords.

 

Comparing SSPR to MFA

Azure AD self-service password reset (SSPR) and MFA may ask for additionalinformation, known as authentication methods or security info, to confirm youare who you say you are when using the associated features.

Administrators can define in policy which authentication methods areavailable to users of SSPR and MFA. Some authentication methods may notbe available to all features.

Microsoft highly recommends Administrators enable users to select more thanthe minimum required number of authentication methods in case they do nothave access to one.

Authentication Method	Usage
Password	MFA and SSPR
Security questions	SSPR Only
Email address	SSPR Only
Microsoft Authenticator app	MFA and Public Preview for SSPR
SMS	MFA and SSPR
Voice call	MFA and SSPR
App passwords	MFA only in certain cases

✔️ Your Azure AD password is considered an authentication method. It is theone method that cannot be disabled.

 

References